Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce unintended stripping of _ filename prefix #106

Merged
merged 1 commit into from
Jun 24, 2020
Merged

Conversation

72636c
Copy link
Member

@72636c 72636c commented Jun 24, 2020

Turns out that this is rather hurtful to __mocks__ and such.

Turns out that this is rather hurtful to `__mocks__` and such.
@72636c 72636c requested a review from a team as a code owner June 24, 2020 03:04
@changeset-bot
Copy link

changeset-bot bot commented Jun 24, 2020

🦋 Changeset is good to go

Latest commit: 7c6a14b

We got this.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@72636c 72636c merged commit aa6e1e8 into master Jun 24, 2020
@72636c 72636c deleted the underscore-prefix branch June 24, 2020 03:13
72636c added a commit that referenced this pull request Jun 26, 2020
This filename manipulation has haunted me as `copyFiles` gets used in
more places. #106 tightened up the matching patterns but a target
repository _could_ have some legitimate reason for storing a filename
with a prefix of `_.` that would still get chomped.

Instead, only trigger this logic on `skuba init` of a built-in template.
There's no reason to do this on `skuba configure`, and external
GitHub-hosted templates shouldn't run into the packaging troubles that
necessitate a `_package.json`.
72636c added a commit that referenced this pull request Jun 26, 2020
This filename manipulation has haunted me as `copyFiles` gets used in
more places. #106 tightened up the matching patterns but a target
repository _could_ have some legitimate reason for storing a filename
with a prefix of `_.` that would still get chomped.

Instead, only trigger this logic on `skuba init` of a built-in template.
There's no reason to do this on `skuba configure`, and external
GitHub-hosted templates shouldn't run into the packaging troubles that
necessitate a `_package.json`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants